Networks are increasingly being deployed with components that utilize the InfiniBand protocol. An InfiniBand network can provide a number of benefits over a network that utilizes more traditional Ethernet and Internet protocols including, for example, a relatively higher signaling rate and a relatively lower latency. However, many network devices are not configured to utilize the InfiniBand protocol, and instead utilize Ethernet and Internet protocols. For example, a computer often will have a network interface controller (“NIC”) to enable the computer to communicate using Ethernet and Internet protocols, but a computer may not have a host channel adapter (“HCA”) to enable the computer to communicate using an InfiniBand protocol.
One technique for obtaining the benefits of InfiniBand in an environment with network devices that are not configured for InfiniBand is to utilize Ethernet over InfiniBand (“EoIB”) or Internet Protocol over InfiniBand (“IPoIB”). With EoIB and IPoIB, a network device may send an Ethernet or IP packet that is received by another device that encapsulates the received packet into an InfiniBand packet. In other words, if using EoIB or IPoIB, the data within an Ethernet or IP packet may be placed within an InfiniBand packet. The InfiniBand packet may traverse an InfiniBand network and may also be decapsulated when exiting at appropriate points such as the InfiniBand network so that traditional Ethernet or IP network devices may read the packet. However, problems with congestion management may arise when utilizing IPoIB and EoIB.
In particular, congestion may occur at a network switch if, for example, the rate of packets passing through the switch is higher than the switch's throughput capacity. Typically, if congestion occurs at a switch, the switch will react according to the protocol of the switch. For example, a packet may be sent from a source computer to a destination computer via a number of switches. Typically, for example, if the packet complies with an Ethernet protocol and is received by router or an Ethernet switch, the router or Ethernet switch may determine that there is congestion. In response to determining that congestion is present, a router or an Ethernet switch may set a value in an Explicit Congestion Notification (“ECN”) field of the packet to notify the destination computer of the congestion and/or may send a packet to the source computer in compliance with a Quantized Congestion Notification (“QCN”) to notify the source computer of the congestion. The source computer and destination computer could then react and adjust to the congestion. Additionally or alternatively, a router or Ethernet switch may drop one or more packets in response to determining that congestion is present.
Similarly, if a packet sent by a source computer complies with an InfiniBand protocol and is received by an InfiniBand switch, the InfiniBand switch may determine that there is congestion. In response to determining that congestion is present, the InfiniBand switch typically may set a value in a Forward Explicit Congestion Notification (“FECN”) field of the packet to notify the destination computer of the congestion and, after receiving the packet, the destination computer may send the source computer a packet with a set value in a Backward Explicit Congestion Notification (“BECN”) field.
However, in a mixed-protocol environment such as EoIB and IPoIB, the traditional methods of resolving congestion may not be effective. For example, if a value in a FECN field of an IPoIB packet is set by an InfiniBand switch, the FECN field may be lost when the packet is decapsulated en route to the destination computer.
Improvements in network congestion management technology, including network congestion management technology in a multi-protocol environment, are desirable.